Tricks of the Mac Game Programming Gurus/TricksOfTheMacGameProgrammingGurus.iso/Information/CSMP Digest/volume 1/csmp-v1-102.txt

Text File | 1994-12-08 | 46.7 KB | 1,358 lines | [TEXT/R*ch]

C.S.M.P. Digest             Tue, 02 Jun 92       Volume 1 : Issue 102

Today's Topics:

    OpenMenuArchitecture/Other Questions...
    HELP:  memory handling problem
    Type Casting PixMaps to BitMaps in PASCAL!
    Program hangs randomly - weird behaviour
    question:THINK C console
    Need a good book to teach me Mac assembly language
    List Manager Question
    LaunchApplication..
    WWDC Dinner News
    Must pascal strings be even word aligned?
    Think C buggy code


The Comp.Sys.Mac.Programmer Digest is moderated by Michael A. Kelly.

These digests are available (by using FTP, account anonymous, your email
address as password) in the pub/mac/csmp-digest directory on ftp.cs.uoregon.
edu.  This is also the home of the comp.sys.mac.programmer Frequently Asked
Questions list.  The last several issues of the digest are available from
sumex-aim.stanford.edu as well.

These digests are also available via email.  Just send a note saying that you
want to be on the digest mailing list to [e-mail], and you will
automatically receive each new digest as it is created.

The digest is a collection of articles from the internet newsgroup comp.sys.
mac.programmer.  It is designed for people who read c.s.m.p. semi-regularly
and want an archive of the discussions.  If you don't know what a newsgroup
is, you probably don't have access to it.  Ask your systems administrator(s)
for details.  (This means you can't post questions to the digest.)

The articles in these digests are taken directly from comp.sys.mac.programmer.
They are not edited; all articles included in this digest are in their original
posted form.  The only articles that are -not- included in these digests are
those which didn't receive any replies (except those that give information
rather than ask a question).  All replies to each article are concatenated
onto the original article in the order in which they were received.  Article
threads are not added to the digests until the last article added to the
thread is at least one month old (this is to ensure that the thread is dead
before adding it to the digests).

Send administrative mail to [e-mail].

-------------------------------------------------------

From: [e-mail] (Steve Klingsporn)
Subject: OpenMenuArchitecture/Other Questions...
Date: 30 Apr 92 19:51:39 GMT
Organization: Brown University


Does anyone know if there is a tech note describing the "Open Scripting
Architecture" (sorry, not menu architecture) so that one's interface
code is separated from one's "engine" code?  I am trying to make
my program (SplitHex) "AppleScript-ready," so when it's released,
all will work right.  What I do now is basically check for menu
events, and if a certain item is hit, I send an Apple event to
myself (a chore), and then process the Apple event the next time
through.

Another question:  You are supposed to be able to have color icons
in a menu, right?  Like in Finder 7 with the "Labels" menu.  I have
tried with a bunch of icons the size of those in Finder 7 to no
avail -- How can I have my own Labels menu?


Thanks.

+++++++++++++++++++++++++++

From: [e-mail]
Organization: Campus Computing Sites, University of Michigan-Ann Arbor
Date: Fri, 1 May 92 18:04:35 GMT

In article <[e-mail]> [e-mail] (Steve Klingsporn) writes:
>
>Does anyone know if there is a tech note describing the "Open Scripting
>Architecture" (sorry, not menu architecture) so that one's interface
>code is separated from one's "engine" code?  I am trying to make
>my program (SplitHex) "AppleScript-ready," so when it's released,
>all will work right.  What I do now is basically check for menu
>events, and if a certain item is hit, I send an Apple event to
>myself (a chore), and then process the Apple event the next time
>through.
>
    I don't believe there is a technotes, but these issues will be
covered in great detail at the WWDC.

    There are different levels of "OSA Compliance" (note these terms are
not official, but they are currently being used) - scriptable, recordable,
attachable and tinkerable.

    Scriptable implies that you support more than the required Apple
events and that you include an 'aete' resource.

    Recordable means that you send events to yourself (using the special
kCurrentProcess trick) that an EventRecorder can pick up.  You should be
sending to self ALL user actions that have Apple events.
    For example in StuffIt 3.0 I record everything
from creating a new archive, to stuffing & unstuffing items to even a
simple rename or delete or an item.  AEQuill (Apple's sample) even records
window movement, since it has an event for that!

    Attachable means that you can execute OSAScripts (AppleScripts) from
within your program directly (button, menu, etc.).  You may also want to
allow users to integrate AScript into your own scripting language - ie. mix
them!

    Tinkerable is still pretty undefined, but was originally proposed as
a way to describe future application that would allow their built-in
functionality to be "overridden" by scripts.


>Another question:  You are supposed to be able to have color icons
>in a menu, right?  Like in Finder 7 with the "Labels" menu.  I have
>tried with a bunch of icons the size of those in Finder 7 to no
>avail -- How can I have my own Labels menu?
>
    Write your own MDEF.  That's what we do in StuffIt!


- --
- -----------------------------------------------------------------------
Leonard Rosenthol          Internet: [e-mail]
Director of Advanced Technology   AppleLink: MACgician
Aladdin Systems, inc.          GEnie:     MACgician

+++++++++++++++++++++++++++

From: [e-mail] (Mark Lanett)
Date: 1 May 92 19:21:49 GMT
Organization: University of Illinois at Urbana

[e-mail] writes:

>In article <[e-mail]> [e-mail] (Steve Klingsporn) writes:

>>Another question:  You are supposed to be able to have color icons
>>in a menu, right?  Like in Finder 7 with the "Labels" menu.  I have
>>tried with a bunch of icons the size of those in Finder 7 to no
>>avail -- How can I have my own Labels menu?
>>
>    Write your own MDEF.  That's what we do in StuffIt!

Ack! The standard MDEF handles color icons just fine. Just create a cicn
with 256 < resource id < 511 and set the icon number in the menu item to
resource id - 256, and you're set. Works exactly the same as normal ICN# and
sicns always did. I haven't tried sizes other than 16x16, though.

Wierd hack: create a 64x64 cicn of id=256 and put it in the system. It doesn't
matter what it looks like, it'll just have a certain effect on other cicns...

Mark L
- --
Mark Lanett, NCSA Software Development                         [e-mail]

---------------------------

From: [e-mail] (Peter Creath)
Subject: HELP:  memory handling problem
Date: 29 Apr 92 12:38:57 GMT
Organization: Cube Technologies

This seems to be giving me random crashes.  What am I doing wrong?
(A Hermes sysop external gets message similar to those from the Control
Panel):


typedef struct {
    DialogPtr    BigDialog;
    short        currentWindow;
    } myStruct;

myStruct        *myVars;

pascal void main(short message, short item, EventRecord *theEvent,
    HermDataPtr myHerm, long *XHRMrefcon, DialogPtr ConfigDialog)
{
if (message == initDev) {
    *XHRMrefcon = (long)NewHandle(sizeof(myStruct));
    if (*XHRMrefcon) {
        MoveHHi((Handle)*XHRMrefcon);
        HNoPurge((Handle)*XHRMrefcon);
        }
    else SysBeep(1);
    }

if (!*XHRMrefcon) return;

HLock((Handle)*XHRMrefcon);
myVars = (myStruct *)(*((Handle)*XHRMrefcon));

switch (message) {
    case initDev:
        myVars->currentWindow = 0;
        myVars->BigDialog = 0L;
        break;
    case closeDev:
        HUnlock((Handle)*XHRMrefcon);
        HPurge((Handle)*XHRMrefcon);
        DisposHandle((Handle)*XHRMrefcon);
        *XHRMrefcon = 0L;
        return;
        break;
    }
HUnlock((Handle)*XHRMrefcon);
}

- ----------------------------------------------------------------------------
Peter Creath                 "When I was a boy I was told that anybody could
[e-mail]   become president; I'm beginning to believe it."
                                                           -- Clarence Darrow

+++++++++++++++++++++++++++

From: [e-mail] (Keith Rollin)
Date: 1 May 92 19:45:27 GMT
Organization: Taligent

In article <[e-mail]>, [e-mail]
(Peter Creath) writes:
>
> This seems to be giving me random crashes.  What am I doing wrong?
> (A Hermes sysop external gets message similar to those from the Control
> Panel):
>

I don't know what's causing you to crash. If you could tell us which line is
causing the crash and why (like "register A0 is bogus"), that would help. In the
meantime, I like to point out a couple of other things (none of which would
cause the crash).

>
> typedef struct {
>     DialogPtr    BigDialog;
>     short        currentWindow;
>     } myStruct;
>
> myStruct        *myVars;
>
> pascal void main(short message, short item, EventRecord *theEvent,
>     HermDataPtr myHerm, long *XHRMrefcon, DialogPtr ConfigDialog)
> {
> if (message == initDev) {
>     *XHRMrefcon = (long)NewHandle(sizeof(myStruct));
>     if (*XHRMrefcon) {
>         MoveHHi((Handle)*XHRMrefcon);
>         HNoPurge((Handle)*XHRMrefcon);

You do not need either of these commands. All MoveHHi will do is waste time. If
you don't lock down the handle after you've moved it high, it will just get
moved around again. Since you don't want to lock the handle at this time, you
don't want the call to MoveHHi, either.

Neither do you need the call to HNoPurge. Handles are unpurgeable by default.

>         }
>     else SysBeep(1);
>     }
>
> if (!*XHRMrefcon) return;
>
> HLock((Handle)*XHRMrefcon);
> myVars = (myStruct *)(*((Handle)*XHRMrefcon));

You do not need to lock the handle here, since you aren't doing anything to move
memory. In the likely case that your REAL external is more complicated and does
move memory around, then you may simply want to lock the handle around the
critical sections of your code.

If you _DO_ lock the handle because you are allocating memory, then you may want
to call MoveHHi just before locking it. For instance, if myVars->BigDialog is
used to point to a dialog that you have created, then you might want to move
your locked handle out of the way before it is created.

>
> switch (message) {
>     case initDev:
>         myVars->currentWindow = 0;
>         myVars->BigDialog = 0L;
>         break;
>     case closeDev:
>         HUnlock((Handle)*XHRMrefcon);
>         HPurge((Handle)*XHRMrefcon);
>         DisposHandle((Handle)*XHRMrefcon);

You do not need to unlock and mark purgeable a handle that you are nuking. Just
call DisposeHandle(). It will work on locked, unpurgeable handles.

>         *XHRMrefcon = 0L;
>         return;
>         break;
>     }
> HUnlock((Handle)*XHRMrefcon);
> }

- --
Keith Rollin
Phantom Programmer
Taligent, Inc.


---------------------------

From: [e-mail] (Josh Adams)
Subject: Type Casting PixMaps to BitMaps in PASCAL!
Date: 27 Apr 92 18:47:28 GMT
Organization: Extended Bulletin Board Service

Please xcuse that lst message, I didn't know my first one had gotten posted
until after I posted the second one which said the same thing, and when I
tried to cancel it , the comp said it wasn't my message. Anyway...

I got some reaction to the last one, but I need to know (I think I need to know
how to type cast a PixMap to a BitMap in PASCAL, so I can use it with
CopyBits. I think that is how I should do it, since they never made a damn
CopyPix which does the same thing as CopyBits. THe one they wrote doesn't
help me at all...

Anyway, any help about the type-casting thing would help,thanks...
Josh

- --
   The opinions expressed are not necessarily those of the University of
     North Carolina at Chapel Hill, the Campus Office for Information
        Technology, or the Experimental Bulletin Board Service.
           internet:  bbs.oit.unc.edu or 152.2.22.80

+++++++++++++++++++++++++++

From: [e-mail] (Matthew Hall)
Date: 28 Apr 92 04:05:19 GMT
Organization: Oberlin College Computer Science

In article <[e-mail]> [e-mail] (Josh Adams) writes:


>   I got some reaction to the last one, but I need to know (I think I need to know
>   how to type cast a PixMap to a BitMap in PASCAL, so I can use it with
>   CopyBits. I think that is how I should do it, since they never made a damn
>   CopyPix which does the same thing as CopyBits. THe one they wrote doesn't
>   help me at all...
>

All right - One way to do this with 32 bit QD is to use the
QDOffScreen library and use GWorlds.  However, I don't know how to do
this so heres the hard way.

var MyColorPort : GrafPtr;  {Yes, not a CGrafPtr}

...
new(MyColorPort);
OpenCPort(MyColorPort); {Will return a color port}

HLock(Handle(MyColorPort^.PortPixMap));   {Lock the ports pixmap}
With MyColorPort^.PortPixMap^^ do
  begin
    rowbytes:=(width*depth)/8 +extra {must be even, better if multiple of 4}
    setrect(bounds,top,left,bottom,right);
    baseaddr:=newptr(rowbytes*(bottom-top));

    rowbytes:= BOR(Rowbytes,$8000);  {The high bit of rowbytes must be
set for QuickDraw to realize that it's a pixmap}
  end;

{A good thing to do is to set the cliprgn of MyColorPort to the
boundsrect, otherwise you might overwrite memory if you draw outside a
box.  Hence Application Zone Damaged}
RectRgn(MyColorPort^.cliprgn,MyColorPort^.portpixmap^^.bounds);
HUnlock(MyColorPort^.portpixmap);


Now, when you want to draw in it, just setport(MyColorPort).  If you
want to copy from it, use

SetPort(MyWindow);
Copybits(MyColorPort^.portbits,MyWindow^.portbits, srcrect, dstrect,
copymode, copyrgn);

ColorQuickdraw senses that it's a pixmap (remember setting the high
bit of rowbytes?) and copies accordingly.

hope this helps
- -matt hall

- --


- -------------------------------------------------------------------------------
Matt Hall.    [e-mail]  OR  [e-mail]
              (216)-775-5805 (That's a Cleveland Area code. Lucky Me)

"If a man comes up to you and says:
    'A dog just carried away your ear.'
Do you run after the dog, or search first for your ear?" - Moon over Morocco


+++++++++++++++++++++++++++

From: [e-mail] (Tommaso Centro 310125/IF {*})
Date: 29 Apr 92 03:38:14 GMT
Organization: D.E.I. Universita' di Padova (Italy)


To copy a pixel map from an off screen color port to a color window for
example i would do like this:
( VAR offPort : CGrafPtr;
      myWindowBw : WindowPtr
      myWindowCol : CWindowPtr )

 CopyBits(GrafPtr(offPort)^.portBits,GrafPtr(myWindowCol)^.portBits,...);
 or (it's the same): CopyBits(...,GrafPtr(myWindowBw)^.portBits,...);

but if you want to use directly pixel maps you can put in your program:

 procedure CopyBits(srcBits:PixMap;dstBits:PixMap;srcRect:Rect;...etc);
 inline
 $A8EC;

and the previous statement becomes:

 CopyBits(offPort^.portPixMap^^,myWindowCol^.portPixMap^^,...);

to have a CWindowPtr you can do like this:
 myWindowBw:=NewCWindow(..);
 myWindowCol:=CWindowPtr(myWindowBw);
or:
 myWindowCol:=CWindowPtr(NewCWindow(...));

I hope this helps.

Ciao
Tommaso

+++++++++++++++++++++++++++

From: [e-mail] (Tommaso Centro 310125/IF {*})
Date: 29 Apr 92 03:29:01 GMT
Organization: D.E.I. Universita' di Padova (Italy)

To copy a pixel map from an off screen color port to a color window for
example i would do like this:
( VAR offPort : CGrafPtr;
      myWindowBw : WindowPtr
      myWindowCol : CWindowPtr )

 CopyBits(GrafPtr(offPort)^.portBits,GrafPtr(myWindowCol)^.portBits,...);
 or (it's the same): CopyBits(...,GrafPtr(myWindowBw)^.portBits,...);

but if you want to use directly pixel maps you can put in your program:

 procedure CopyBits(srcBits:PixMap;dstBits:PixMap;srcRect:Rect;...etc);
 inline
 $A8EC;

and the previous statement becomes:

 CopyBits(offPort^.portPixMap^^,myWindowCol^.portPixMap^^,...);

to have a CWindowPtr you can do like this:
 myWindowBw:=NewCWindow(..);
 myWindowCol:=CWindowPtr(myWindowBw);
or:
 myWindowCol:=CWindowPtr(NewCWindow(...));

I hope this helps.

Ciao
Tommaso

+++++++++++++++++++++++++++

From: [e-mail] (JohnC)
Date: 29 Apr 92 18:45:13 GMT
Organization: The Royal Society for Putting Things on Top of Other Things

In article <[e-mail]> [e-mail] (Tommaso Centro 310125/IF {*}) writes:
>but if you want to use directly pixel maps you can put in your program:
>
> procedure CopyBits(srcBits:PixMap;dstBits:PixMap;srcRect:Rect;...etc);
> inline
> $A8EC;
>
>and the previous statement becomes:
>
> CopyBits(offPort^.portPixMap^^,myWindowCol^.portPixMap^^,...);

Excellent idea, except _please_ don't re-define the existing name.  Instead,
you should add something like the following:

  procedure CopyPix(srcPix:PixMap;dstPix:PixMap;srcRect:Rect;...etc);
  inline
  $A8EC;

  procedure CopyBitsToPix(srcBits:BitMap;dstPix:PixMap;srcRect:Rect;...etc);
  inline
  $A8EC;

  procedure CopyPixToBits(srcPix:PixMap;dstBits:BitMap;srcRect:Rect;...etc);
  inline
  $A8EC;


There, that covers all the possibilities. :-)

- --
John Cavallino                  |  EMail: [e-mail]
University of Chicago Hospitals |         [e-mail]
Office of Facilities Management | USMail: 5841 S. Maryland Ave, MC 0953
B0 f++ c+ g+ k s++ e+ h- pv     |         Chicago, IL  60637

+++++++++++++++++++++++++++

From: [e-mail]
Date: 30 Apr 92 18:21:14 EST
Organization: Wright State University

In article <[e-mail]>, [e-mail] (JohnC) writes:
> In article <[e-mail]> [e-mail] (Tommaso Centro 310125/IF {*}) writes:
> Excellent idea, except _please_ don't re-define the existing name.  Instead,
> you should add something like the following:
>
>   procedure CopyPix(srcPix:PixMap;dstPix:PixMap;srcRect:Rect;...etc);
>   inline
>   $A8EC;
[ variations omitted ]

IM V tells us that CopyBits uses the portVersifield of a CGrafPort
to decide if it's been handed a BitMap or a PixMapHandle. At the
same time, CopyBits appears to be happy with a PixMap (passed by
address). Is this CopyBits magic or am I overlooking something
obvious.

o----------------------------------------------------------------------------o
| John B. Matthews, [e-mail], disclaimer:= myViews <> WSU |
| "I'm a commensal .sig virus, indistinguishable from an ordinary organelle."|
o----------------------------------------------------------------------------o

---------------------------

From: [e-mail] (Gerald Siek)
Subject: Program hangs randomly - weird behaviour
Date: 29 Apr 92 14:03:47 GMT
Organization: Uni-GH Paderborn

Hello experts!

I have a *very* weird problem:
I'm porting a huge UNIX programm (a computer algebra system) to the
Macintosh.   The port was not too difficult but after a few weeks
the program began to behave very strange.

The program does not always start up correctly, sometime it simply
seems to hang in a loop.  The Mac does not crash, I can still move
the mouse but the program does not finish it's initialization.
When I trace the program with the debugger it always runs fine so
I have no possibility to see where it hangs.

So I put output commands (commands that write "Now executing xyz" in
a window) at several places in the initialization part to see which
routines are executed correctly.  And now the program works *fine*.
When I remove the output commands the program becomes unstable again.

I have no real idea what could be the reason for this.  The programm simply
behaves different when I add the output commands.  The program makes
heavy use of malloc and free calls and shuffels LARGE amounts of memory.
Has anyone encountered a similar problem?  Perhaps a memory management
problem? (I use THINK C 5.0.2)

ANY help, ANY clue is greatly appreciated

Thanks
    Jerry
- --
  Gerald Siek  -  [e-mail]  -  University of Paderborn, Germany

+++++++++++++++++++++++++++

From: [e-mail] (Donald T. Major)
Organization: SAS Institute Inc.
Date: Wed, 29 Apr 1992 18:02:18 GMT

In article <[e-mail]>, [e-mail] (Gerald Siek) writes:
 [stuff deleted]
|> When I trace the program with the debugger it always runs fine so
|> I have no possibility to see where it hangs.
 [stuff deleted]
|> So I put output commands (commands that write "Now executing xyz" in
|> a window) at several places in the initialization part to see which
|> routines are executed correctly.  And now the program works *fine*.
|> When I remove the output commands the program becomes unstable again.
 [stuff deleted]

Any time I see something like this in my mac code, it has always been a
sign of either uninitialized variables or insufficiently allocated
variables (static, automatic, or dynamic).

                                                     ..
                                                    dtm

- --
Donald Major       SAS Institute Inc.  "Cicely, let's fling something!"
[e-mail] SAS Campus Drive                 - Northern Exposure
[phone]     Cary, NC 27513-2414

+++++++++++++++++++++++++++

From: [e-mail] (Jack Herrington)
Date: 1 May 92 19:50:08 GMT
Organization: University of Miami Medical School

[e-mail] (Gerald Siek) writes:
: The program does not always start up correctly, sometime it simply
: seems to hang in a loop.  The Mac does not crash, I can still move
: the mouse but the program does not finish it's initialization.
: When I trace the program with the debugger it always runs fine so
: I have no possibility to see where it hangs.

Look for large external or internal (inside procedures) initization's of
variables.  If you find them, replace them with a NewPtr or NewHandle (but
if you use handles, start reading the memory manager sections on HLock
HUnlock, HGetState, and HSetState).  These types of problems will be
especially evident when you move between different types of Macs, Mac
Pluses do not allow a great amount of external space, while a Mac II CX is
more forgiving.

- -Jack
- --
"Electric word 'life', it means forever and that's a might long time.  But I'm
 here to tell yah, there's something else... The after-life, a word of
 never-ending happiness, you can always see the sun, day or night.  So when you
 call up that shrink in Beverly hills, you know the one, Dr. everything-we-all-

---------------------------

Subject: question:THINK C console
From: [e-mail] (Eli K. Burk)
Date: 30 Apr 92 19:47:06 PDT

I posted to this group a few weeks ago about using THINK C while
learning C and the mac environment.

I have learned that I am best served just learning C. It keeps
me plenty busy. So now my question becomes - how can I modify
the console package to:
    1) support a scroll bar
    2) exit like a "regular mac app" by command-q ONLY
    3) have the name of my "simple console app" appear
           on the title bar of the window (it may aready do
       this - I haven't used THINK C in weeks)
    4) cut and paste ability (if this is complex - I'll skip it...)
Also I want to learn just enough about resources to be able to:
    1) use the info menu
    2) set an icon to "simple console app"
Has anyone tired to use the curses package in THINK C - I know
this is a waste - but I just don't have the time now to learn
*real* mac programming. - Also I don't even own a mac...

If my questions include errors or misstatements just correct me.

email please.

- --
Eli Burk                   [e-mail]  <---NeXT mail ok
P.O. Box 22135             "de do do do de da da da" sting at his best
San Francisco, CA 94122    "me me me me me me me me" sting at his worst


---------------------------

From: [e-mail] (Brian Westphal)
Subject: Need a good book to teach me Mac assembly language
Date: 1 May 92 05:58:19 GMT
Organization: University of Michigan, ITD Consulting and Support Services

I am interested in learning the ins and outs of assembly language programming
for the Mac, and am wondering which book could best help me to do this.  I
already know and use assembly on other machines so it isn't new to me, but I
don't know the instruction set for the 60xxx series, and all the fine points
that are Mac specific.  If you know of a great book that can help me do this
please e-mail me.  Also, what's the best Mac assembler?  Do I have to invest
in MPW?  I would rather not.  Thanks to all.
- --
_______________________________________________________________________________
MMMMMMMMM        MMMMMMMMM |                   Brian Westphal
MMMMMMMMMM      MMMMMMMMMM |               College of Engineering
MMMMMMMMMMM    MMMMMMMMMMM |---------------------------------------------------

+++++++++++++++++++++++++++

From: [e-mail] (Charles B. Cranston)
Organization: UM Home for the Terminally Analytical
Date: Fri, 1 May 1992 22:01:06 GMT

In article <[e-mail]>, [e-mail] (Brian Westphal) writes:

> I am interested in learning the ins and outs of assembly language programming
> for the Mac, and am wondering which book could best help me to do this.  I

You need the Motorola book(s) on the 680x0 processor itself

Then maybe one of these:

"The Complete Book Of Macintosh Assembly Language Programming"
(Dan Weston, two volume set)
Scott Foresman & Co ISBN #s 0-673-18379-3 & 0-673-18583-4

"Programming the Macintosh in Assembly Language"
(James W. Coffron and/or Steve Williams?)
SYBEX ISBN 0-89588-263-9

"Programming the 68000: Macintosh Assembly Language"
(Edwin Rosenzweig and Harland Harrison)
Hayden ISBN 0-8104-6310-5

"MPW and Assembly Language Programming For The Macintosh"
(Scott Kronick)
Hayden ISBN 0-672-48409-9


---------------------------

From: [e-mail] (Steve Herman)
Subject: List Manager Question
Organization: Boeing Computer Support Services (BCSS)
Date: Fri, 1 May 1992 20:08:33 GMT

     I'm attempting to use the List Manager to create a list box which
contains 2 columns of related strings.  I would like to be able to highlight
the entire row (ie both columns) whenever a cell is clicked.  This seems to
be relatively simple except while LClick() is tracking the mouse.  While
LClick() is handling the mouse tracking only the single cell under the mouse
is highlighted.  It would certainly look nicer if I could highlight the
entire row while the mouse was being tracked.

    Does anyone know if this can be done?  I'm working in THINK C 5.0.


Thanks,
Steve

- -------------------------------------
Steve Herman
"Happiness is just a 'Flaming Moe' away"
- -------------------------------------

+++++++++++++++++++++++++++

From: [e-mail] (Doug McNaught)
Organization: California Institute of Technology
Date: Sat, 2 May 1992 05:05:12 GMT

In article <[e-mail]> [e-mail] (Steve Herman) writes:


>   I'm attempting to use the List Manager to create a list box which
>contains 2 columns of related strings.  I would like to be able to
>highlight the entire row (ie both columns) whenever a cell is
>clicked.  This seems to be relatively simple except while LClick() is
>tracking the mouse.  While LClick() is handling the mouse tracking
>only the single cell under the mouse is highlighted.  It would
>certainly look nicer if I could highlight the entire row while the
>mouse was being tracked.


>   Does anyone know if this can be done?  I'm working in THINK C 5.0.

  If these two strings will never be selected separately, this should
be fairly easy. Just store both strings in one cell (using whatever
data structure you like) and write an LDEF that draws them both. If
there is some case where one of the columns will be individually
selected, you'd have to patch something out and be generally skanky.
>From your text above it looks like the first solution will do fine for
you. Don't be scared by LDEFs, they're really easy.

regards,
doug
- --
Doug McNaught              |"Sadder still to watch it die/ Then never to have
[e-mail]      | known it/ For you, the blind who once could see/
[e-mail] | The bell tolls for thee..." --Neil Peart
  Nobody approves my opinions! Not even me, sometimes. Read at your own risk.

---------------------------

From: [e-mail] (Sean Hall - CS460)
Subject: LaunchApplication..
Organization: Washington State University
Date: Fri, 1 May 92 20:49:35 GMT

I am trying to launch one app from another.  In experimenting with THINK C 5
I find that launching another app causes the launching app to quit.  Also,
if I try using the ansi library printf, it bombs or dont work at all.  This is
a mystery to me.  I have multifinder aware, accept HLE marked in the project.
Also, the receiving app accepts HLE and works fine if double clicked.
Here is the code for the "sender"

#include <AppleEvents.h>
#include <processes.h>
#define NIL 0
void mySend(void);

main()
{
OSErr myErr;
DTPBRec DTpb;
FSSpec myFSSpec;
LaunchParamBlockRec    L;
Str255 name;
int x;

    DTpb.ioVRefNum = -1;
    DTpb.ioNamePtr = name;

    myErr = PBDTGetPath(&DTpb);
    DTpb.ioFileCreator = (long)'MyAp';
    DTpb.ioIndex = 0;
    myErr = PBDTGetAPPLSync(&DTpb);
    myErr = FSMakeFSSpec(DTpb.ioVRefNum,DTpb.ioAPPLParID,
                 DTpb.ioNamePtr, &myFSSpec);
    L.launchBlockID = extendedBlock;
    L.launchEPBLength = extendedBlockLen;
    L.launchControlFlags = launchNoFileFlags;
    L.launchAppParameters = 0;
    L.launchAppSpec = &myFSSpec;

    LaunchApplication(&L);
}

Comments welcome.
- -Sean


+++++++++++++++++++++++++++

From: [e-mail] (Carl W. Haynes III)
Date: 2 May 92 00:33:01 GMT
Organization: Purdue University Computing Center

In article <[e-mail]> [e-mail] (Sean Hall - CS460) writes:
>I am trying to launch one app from another.  In experimenting with THINK C 5
>I find that launching another app causes the launching app to quit.  Also,
>if I try using the ansi library printf, it bombs or dont work at all.  This is
>a mystery to me.  I have multifinder aware, accept HLE marked in the project.
>Also, the receiving app accepts HLE and works fine if double clicked.
>Here is the code for the "sender"
>

   [most of the code deleted]

>    L.launchBlockID = extendedBlock;
>    L.launchEPBLength = extendedBlockLen;
>    L.launchControlFlags = launchNoFileFlags;
                           ^^^^^^^^^^^^^^^^^^

This is the problem, it should read:

    L.launchControlFlags = launchNoFileFlags + launchContinue;

IM VI 29-15 has a description of all the flags available

carl
[e-mail]
AOL: CWH3

---------------------------

From: [e-mail] (Michael Peirce)
Subject: WWDC Dinner News
Date: 24 Apr 92 23:47:01 GMT
Organization: Peirce Software

We're just shy of 50 people.  I'll be checking with Gorden Biersch
about accomidating us.  I *think* they can handle it.

We'll be meeting at the main doors of the San Jose Convention Center
(where the WWDC is held) at 7:45 and then head over there en masse.

(And I though all the Mac people had defected to Windows! :-)

Stephan Somogyi                    [e-mail]
Marshall Clow                    [e-mail]
Rick Holzgraf                    [e-mail]
Larry Rosenstein                [e-mail]
Oliver Breidenbach                [e-mail]
Michael Hecht                    [e-mail]
Roland Mansson                    [e-mail]
Jon W{tte + 1                    [e-mail]
Grobbins                        [e-mail]
Amanda Walker                    [e-mail]
Owen M. Hartnett                [e-mail]
D. Jay Newman                    [e-mail]
Gavin Eadie                        [e-mail]
Brian Schipper                    [e-mail]
Eric Schlegel                    [e-mail]
Steven Nicolai                    [e-mail]
Herb Poppe                        [e-mail]

    New folks since last posting...

Paul Snively                    [e-mail]
Kent Sandvik                    [e-mail]
Tom Lippincott                    [e-mail]
Wes W. Price II + 2                 [e-mail]
John Coolidge                    [e-mail]
Neal Trautman                    [e-mail]
Mike Engber                        [e-mail]
Kent Borg                         [e-mail]
Matthew Mora                    [e-mail]
Tim Dierks                        [e-mail]
Leonard Rosenthol                [e-mail]
Greg Anderson                    [e-mail]
Jan-Erik Mangs                    [e-mail]
Ragnar Sundblad                    [e-mail]
Patrik Faltstrom                [e-mail]
Roy Lovejoy                        [e-mail]
Brian M. Hamlin                    [e-mail]
Jon Pugh                        [e-mail]
Martin Gannholm                    [e-mail]
Jerry Shields                    [e-mail]
Jeff Holcomb                    [e-mail]
Guy Riddle                        [e-mail]
Steve Lemke                        [e-mail]
Arno Gourdol                    [e-mail]
Laurie Kirchmeier                [e-mail]

- --  Michael Peirce         --   [e-mail]
- --  Peirce Software        --   Suite 301, 719 Hibiscus Place
- --  Macintosh Programming  --   San Jose, California USA 95117
- --           & Consulting  --   voice: [phone] fax: [phone]
- --                         --   AppleLink: peirce & America Online: AFC Peirce

+++++++++++++++++++++++++++

From: [e-mail] (Kent Sandvik)
Date: 27 Apr 92 02:58:36 GMT
Organization: MacDTS Mongols

In article <[e-mail]>, [e-mail]
(Michael Peirce) writes:
>
> We're just shy of 50 people.  I'll be checking with Gorden Biersch
> about accomidating us.  I *think* they can handle it.
>
> We'll be meeting at the main doors of the San Jose Convention Center
> (where the WWDC is held) at 7:45 and then head over there en masse.
>
> (And I though all the Mac people had defected to Windows! :-)
>
> Stephan Somogyi                    [e-mail]
> Marshall Clow                    [e-mail]
> Rick Holzgraf                    [e-mail]
> Larry Rosenstein                [e-mail]
> Oliver Breidenbach                [e-mail]
> Michael Hecht                    [e-mail]
> Roland Mansson                    [e-mail]
> Jon W{tte + 1                    [e-mail]
> Grobbins                        [e-mail]
> Amanda Walker                    [e-mail]
> Owen M. Hartnett                [e-mail]
> D. Jay Newman                    [e-mail]
> Gavin Eadie                        [e-mail]
> Brian Schipper                    [e-mail]
> Eric Schlegel                    [e-mail]
> Steven Nicolai                    [e-mail]
> Herb Poppe                        [e-mail]
>
>     New folks since last posting...
>
> Paul Snively                    [e-mail]
> Kent Sandvik                    [e-mail]
> Tom Lippincott                    [e-mail]
> Wes W. Price II + 2                 [e-mail]
> John Coolidge                    [e-mail]
> Neal Trautman                    [e-mail]
> Mike Engber                        [e-mail]
> Kent Borg                         [e-mail]
> Matthew Mora                    [e-mail]
> Tim Dierks                        [e-mail]
> Leonard Rosenthol                [e-mail]
> Greg Anderson                    [e-mail]
> Jan-Erik Mangs                    [e-mail]
> Ragnar Sundblad                    [e-mail]
> Patrik Faltstrom                [e-mail]
> Roy Lovejoy                        [e-mail]
> Brian M. Hamlin                    [e-mail]
> Jon Pugh                        [e-mail]
> Martin Gannholm                    [e-mail]
> Jerry Shields                    [e-mail]
> Jeff Holcomb                    [e-mail]
> Guy Riddle                        [e-mail]
> Steve Lemke                        [e-mail]
> Arno Gourdol                    [e-mail]
> Laurie Kirchmeier                [e-mail]

Interesting, of this list (where the majority are of course Americans) we
have 6.5 Swedes (I count myself as a 0.5 Swede). Are we taking over the
Mac hacking world? Don't know if Greg Anderson also has a little bit
viking blood in his veins?

Cheers,
Kent

+++++++++++++++++++++++++++

From: [e-mail] (Michael Peirce)
Date: 27 Apr 92 15:34:20 GMT
Organization: Peirce Software


In article <[e-mail]> (comp.sys.mac.programmer), [e-mail] (Kent Sandvik) writes:
>
> Interesting, of this list (where the majority are of course Americans) we
> have 6.5 Swedes (I count myself as a 0.5 Swede). Are we taking over the
> Mac hacking world? Don't know if Greg Anderson also has a little bit
> viking blood in his veins?

My theory is that they heard that Gorden Biersch makes EXCELLENT beer! :-)

- --  Michael Peirce         --   [e-mail]
- --  Peirce Software        --   Suite 301, 719 Hibiscus Place
- --  Macintosh Programming  --   San Jose, California USA 95117
- --           & Consulting  --   voice: [phone] fax: [phone]
- --                         --   AppleLink: peirce & America Online: AFC Peirce

+++++++++++++++++++++++++++

From: [e-mail] (Paul G. Smith)
Date: 29 Apr 92 14:08:52 GMT
Organization: CommsTalk HQ


Re article <[e-mail]> (comp.sys.mac.programmer):

Errr... any room for a UK-based netter at the WWDC dinner?

We've only just got our newsfeed working, after a (long) while without a
connection, or I'd have sent this earlier.

Oh, and by the way: what night is it?

best regards, Paul

- -------------------------------------
Paul G Smith / CommsTalk HQ
INTERNET:  "[e-mail]"            CIX:  "pgsmith"
AppleLink: "commstalk.hq" ("[e-mail]")
tel/fax:   + 44 491 574295  (dial 11 on 2nd dial tone for fax)
snail:    40 St Marks Road, Henley-on-Thames, Oxon. RG9 1LW. UK

+++++++++++++++++++++++++++

From: [e-mail] (Laurie Kirchmeier)
Date: 30 Apr 92 14:59:52 GMT
Organization: Office of Instructional Tech./ Univ of Michigan

There's at least two Brits in the list - Gavin Eadie and myself.

+++++++++++++++++++++++++++

From: [e-mail] (Paul G. Smith)
Date: 1 May 92 19:03:42 GMT
Organization: CommsTalk HQ


In article <[e-mail]> (comp.sys.mac.programmer), [e-mail] (Laurie Kirchmeier) writes:
> There's at least two Brits in the list - Gavin Eadie and myself

All the better, then. :-)

How do I go about making myself the third, then?

best regards, Paul

- -------------------------------------
Paul G Smith / CommsTalk HQ
INTERNET:  "[e-mail]"            CIX:  "pgsmith"
AppleLink: "commstalk.hq" ("[e-mail]")
tel/fax:   + 44 491 574295  (dial 11 on 2nd dial tone for fax)
snail:    40 St Marks Road, Henley-on-Thames, Oxon. RG9 1LW. UK

---------------------------

From: Jim Cook <[e-mail]>
Subject: Must pascal strings be even word aligned?
Organization: Prime Computer, Inc.
Date: Wed, 29 Apr 1992 21:05:45 GMT

In Apple Mac Tech note 189, the structure of a 'vers' resource record format
is discussed.  It contains a short and a long version string, both of which
are pascal strings.  They are compressed so the long string immediately
follows the long string, with no padding, which means it may be odd byte
aligned.

The code examples in the note show the long version being copies via a
BlockMove to another pascal string variable which is even byte aligned to
insure the long version string is even word aligned before they do anything
with it.

Why?

I haven't seen anything anywhere that says pascal strings (or any other
string for that matter) must be even byte aligned.  I was only aware of
this requirement for larger objects such as shorts, longs, etc. and only
on the 68000, not the 68020 or 68030.

Thanks if you can shed any light.

Jim
<[e-mail]>


+++++++++++++++++++++++++++

From: [e-mail] (Chris D. Nebel)
Organization: University of Maryland at College Park
Date: Thu, 30 Apr 1992 18:15:31 GMT

In article <[e-mail]> <[e-mail]> writes:
>I haven't seen anything anywhere that says pascal strings (or any other
>string for that matter) must be even byte aligned.  I was only aware of
>this requirement for larger objects such as shorts, longs, etc. and only
>on the 68000, not the 68020 or 68030.

Well, you're right, it does only apply to 68000s.  But you *could* be running
on one, you know!  I think the problem is that many Pascal compilers, when
you say something like "aString := anotherString", generate code that moves
a long word at a time.  Usually this is perfectly safe, because variables
bigger than byte size are always word aligned.  BUT, sometimes you get these
structures where strings are packed together like you describe, so if you
try to do a direct string assign, you'll crash on a 68000.  I got bitten
by this one trying to fiddle with font name records in FONDs.

Chris Nebel
[e-mail]

+++++++++++++++++++++++++++

From: [e-mail] (Larry Rosenstein)
Date: 1 May 92 21:58:23 GMT
Organization: Taligent, Inc.

In article <[e-mail]>, [e-mail] (Jim
Cook) wrote:
>
> I haven't seen anything anywhere that says pascal strings (or any other
> string for that matter) must be even byte aligned.  I was only aware of

In fact, items in standard menus are Pascal strings and not necessarily byte
aligned.  This causes problems if you need to parse the menu data on a 68000
machine.

- -----
Larry Rosenstein
Taligent, Inc.
[e-mail]

---------------------------

From: [e-mail] (Marc A. Lombardo)
Subject: Think C buggy code
Date: 29 Apr 92 21:53:26 GMT
Organization: Case Western Reserve University, Cleveland, OH (USA)



  Hello!

  I have written a small scroller in Think C to get acquainted with pointers
and strings in C.  I have been having some rather annoying problems with
the code I have written, but again, I assume it is my fault and that is why
I have decided to post the code to Usenet for people to rip apart and tell
me what is wrong.


  The program is SUPPOSED to exit when a key is pressed, but that doesn't
work at all.  The main problem that I am having with the code is that if I
include the line in comments directly under the sl=strlen(scroll);
statement, the scroller will work! (Well, I haven't tested it completely,
but it looks like it is scrolling!)  If I do NOT include this line, it will
not scroll at all!  The problem is that this line has nothing to do with the
scroller as far as I know... All I am doing is printing 7 spaces, no less,
to the screen with a \n at the end.  For some reason this makes the scroller
work.

  I would be very happy to know why this happens, for I came upon it by
complete accident!  But, if you see some other problems in my code, or have
suggestions about how to do something differently, I would be happy to hear
what you have to say, for I am learning C all on my own, and I can use all
of the help I can get.

     Please reply via email!


Here is the buggy code:  (pretty short!)



- ----

#include <stdio.h>
#include <console.h>

main()
{
     char ch;
     char *scroll,temp[10];

     int x,sl,i,t;
     csetmode(C_RAW,stdin);

     scroll="This is a test of the emergency broadcast system... this is
only a test.  If this were a real emergency then this test would be followed
by blah blah blah blah blah";

     sl=strlen(scroll);

  /* printf("       \n");     */

     for(x=0;x<10;x++)  {               /* Can you forget about the
          temp[x]=scroll[x];               brackets if there is only
     }                                     one line in your loop?  */

     strcat(scroll,temp);

     ch=-1;

     while (ch==-1) {
          for(x=0;x<sl-10;x++) {
               if ((ch=getchar())==-1) {
                    t=0;
                    for(i=x;i<x+10;i++) {
                         temp[t++]=scroll[i];
                    }
                    cgotoxy(10,10,stdout);
                    printf("%s",temp);
               }
          }
     }
}

- --
Marc A. Lombardo                                            User Address: an172
/-\-/-\-/-\-/-\-/-\-/-\-/-\-/-\-/-\-/-\-/-\-/-\-/-\-/-\-/-\-/-\-/-\-/-\-/-\-/-\
    Compuserve:  >INTERNET: [e-mail]
    Internet/BitNET:  [e-mail]         Atari ST,MIDI,Music

+++++++++++++++++++++++++++

From: [e-mail] (Brian Cox)
Date: 30 Apr 92 20:23:22 GMT
Organization: Acuson; Mountain View, California

[e-mail] (Marc A. Lombardo) writes:

First of all, it is not unusual for printf() to alter the behavior of
seemingly unrelated bugs.  It scrambles the stack up and tends to move
things around.


>Here is the buggy code:  (pretty short!)



>----

>#include <stdio.h>
>#include <console.h>

>main()
>{
>     char ch;
>     char *scroll,temp[10];

>     int x,sl,i,t;
>     csetmode(C_RAW,stdin);

>     scroll="This is a test of the emergency broadcast system... this is
>only a test.  If this were a real emergency then this test would be followed
>by blah blah blah blah blah";

So: we have a pointer "scroll" which points at a block of static memory
    which has "This is a test...blah"  The block of memory is exactly as
    long as the text you typed in.  This is important for later...
>
>     sl=strlen(scroll);

>  /* printf("       \n");     */

>     for(x=0;x<10;x++)  {               /* Can you forget about the
>          temp[x]=scroll[x];               brackets if there is only
>     }                                     one line in your loop?  */

Now: we copy the first 10 bytes from scroll into temp.  Note that temp
     now has 10 bytes in it, but no null termination.  strcat() really
     prefers that its arguments be null terminated.  Note also that if
     you added a line: temp[x] = '\0'; after the for loop, you would
     be off the end of the array.

>     strcat(scroll,temp);

Ahh: here is where the problem comes to a head!  temp is not null terminated
     and scroll is only big enough to hold what it already contains!  Who
     knows how many bytes will be copied from temp until the random data
     beyond happens to be 0?  And who knows what variable, whose memory
     happens to be right after scroll, will be overwritten in this "drive-by"
     shooting?  This is exactly the sort of behavior which can be altered
     by inserting printf()'s by the way.

>     ch=-1;

We're already screwed up by the time we get here.  But you want to watch out
for putting negative values into char variables.  Some compilers treat chars
as unsigned.  I don't recall off the top of my head, but I think that this
is OK in THINK C...

>     while (ch==-1) {
>          for(x=0;x<sl-10;x++) {
>               if ((ch=getchar())==-1) {

You will notice that in K&R, that c, which gets the value of getchar() is
declared an int for the very reason I mentioned above.

>                    t=0;
>                    for(i=x;i<x+10;i++) {
>                         temp[t++]=scroll[i];
>                    }
>                    cgotoxy(10,10,stdout);
>                    printf("%s",temp);
>               }
>          }
>     }
>}

>--
>Marc A. Lombardo                                            User Address: an172
>/-\-/-\-/-\-/-\-/-\-/-\-/-\-/-\-/-\-/-\-/-\-/-\-/-\-/-\-/-\-/-\-/-\-/-\-/-\-/-\
>    Compuserve:  >INTERNET: [e-mail]
>    Internet/BitNET:  [e-mail]         Atari ST,MIDI,Music

Hope this was informative and not too insulting.

                -_Brian Cox_-

- --
- --------------------------------------------------------------------------------
Make sure that you do not to overanalyze the crud that comes out of your
keyboard when you turn it upside down and shake it...

---------------------------

End of C.S.M.P. Digest
**********************